refactor: Build user input prompts with intent constructors by tiurin · Pull Request #459 · localstack/lstk

tiurin · 2026-08-13T17:26:09Z

Motivation

#457 and #458 each fixed one prompt that had shipped with the wrong layout, and the review comment on #457 wrote down the rule they were both applying:

Inline Y/n for binary confirmations: "Remove snapshot? [y/N]"

Vertical choices for distinct actions: "Keep waiting", "Stop and exit", etc.

That rule is not written anywhere. UserInputRequestEvent asked its author for a Vertical bool, which is a rendering decision. It is easy to leave the field out which defaults to inline.

Also, labels had drifted into three styles at once: [ENTER] Log in again, Update now [U], and a bare AWS advertising no key at all.

Solution

Give user input a vocabulary of intents and derive the layout from it. User promts can be built using one of the new constructors in internal/output/prompt.go. The developer uses the appropriate prompt type which automatically applies the design rule :

Constructor	What it is	Rendering
`output.Confirm(prompt, DefaultYes\|DefaultNo, ch)`	y/n on an action the user already requested	inline `[y/N]`, capitalized answer is what ENTER picks
`output.ActionChoice(prompt, options, ch)`	a choice between distinct outcomes	one selectable row per option
`output.Acknowledge(prompt, label, ch)`	a single keypress, no choice	inline

UserInputRequestEvent can't be used directly, but can be easily extended with a new prompt type if needed. See technical details:

Technical details

To enforce the usage of constructors, UserInputRequestEvent's fields are unexported - this is done by renaming variables from uppercase to lowercase and read-only accessors are added. This way a struct literal built anywhere outside internal/output does not compile:

internal/reset/reset.go:43:36: unknown field Prompt in struct literal of type
output.UserInputRequestEvent, but does have unexported prompt

Unexporting only Vertical would not have worked — Go lets a keyed literal from another package omit unexported fields, so the bypass would still compile and would still default to the inline layout that caused the bug. Removing every exported field is what closes it. UserInputRequestEvent{} remains legal but inert: no prompt, nil channel, nothing settable.

Behavior changes

The default has been changed to No for lstk snapshot remove. Rationale - other destructive operations, e.g. lstk reset, lstk volume clear, have No as a default - meaning that accidentally pressing Enter does not perform an operation that cannot be undone. I've made snapshot remove consistent with the rest. See comments in review below: #459 (comment)

Review

I've reviewed the code and tested the behaviour manually. I've also shortened generated comments and claude instructions.

I've added a self-review with examples of inconsistencies that this PR fixes and prevents in the future.

Validation

go test ./internal/... ./cmd/... -count=1
golangci-lint run ./... — 0 issues
make build
Seal proved by adding a raw literal to internal/reset/reset.go and confirming go build ./... rejects it

Follow-up to #457 and #458.

Closes DEVX-1057

tiurin

I've added examples of inconsistencies that are fixed and should be prevented in the future by this refactoring.

tiurin · 2026-08-17T17:10:34Z

-			m.sink.Emit(output.UserInputRequestEvent{
-				Prompt: "LocalStack is still starting. Check progress with 'lstk logs'.",
-				Options: []output.InputOption{
-					{Key: "w", Label: "[W] Keep waiting"},
-					{Key: "s", Label: "[S] Stop and exit"},
+			m.sink.Emit(output.ActionChoice(
+				"LocalStack is still starting. Check progress with 'lstk logs'.",
+				[]output.InputOption{
+					{Key: "w", Label: "Keep waiting"},
+					{Key: "s", Label: "Stop and exit"},
 				},
-				ResponseCh: responseCh,
-				Vertical:   true,
-			})


This shows well the key benefits of the change.

name talks about a specific intent

rendering details that are easy to miss (Vertical) are hidden behind ActionChoice implementation.

Key rendering like [W] is derived from the key itself, doesn't leave a place for drift

tiurin · 2026-08-17T17:11:57Z

-			Prompt: "Reset emulator state? All resources will be lost",
-			Options: []output.InputOption{
-				{Key: "y", Label: "Yes"},
-				{Key: "n", Label: "NO"},


Was inconsistent with the rest of y/n prompts: Yes/NO here, y/N everywhere else.

tiurin · 2026-08-17T17:27:53Z

 	responseCh := make(chan output.InputResponse, 1)
-	sink.Emit(output.UserInputRequestEvent{
-		Prompt:     "Which emulator would you like to use?",
-		Options:    options,


Actual shortcut keys to select the emulators were not displayed because ShortName() didn't contain the text:

It's hard to understand while writing the code because InputOption receives both key and label, so agents often assume label doesn't need to contain the key shortcut prefix in their text.

With the refactoring the rendering is left to the ActionChoice implementation and is consistent between usages - shortcut keys are always displayed if provided. prevents the problem and keeps ShortName() clear and without a possibility to drift from defined shortcut key to what is typed in the label

tiurin · 2026-08-18T10:32:14Z

 	responseCh := make(chan output.InputResponse, 1)
-	sink.Emit(output.UserInputRequestEvent{
-		Prompt:     "Update lstk to latest version?",
-		Options:    []output.InputOption{{Key: "u", Label: "Update now [U]"}, {Key: "r", Label: "Remind me next time [R]"}, {Key: "s", Label: "Skip this version [S]"}},


Here key shortcut was printed as a suffix (Update now [U]), while in every other user prompt it is a prefix (e.g. [R] Re-authenticate).

Leaving rendering the shortcuts to ActionChoice implementation rather than typing it out in a label string keeps the formatting consistent across CLI.

tiurin · 2026-08-18T12:40:36Z

-	Options    []InputOption
-	ResponseCh chan<- InputResponse
-	Vertical   bool
+	prompt     string


Keeping fields package-private by using lowercase names. This means UserInputRequestEvent can't be meaningfully instantiated directly. prompt.go is in the same package so new constructors can set these fields when they build an instance.

tiurin · 2026-08-18T13:46:00Z

-		})
+		sink.Emit(output.Confirm(
+			fmt.Sprintf("Delete cloud snapshot 'pod:%s'? This operation cannot be undone.", podName),
+			output.DefaultNo,


There is a behaviour change here - the default is changed to No. Rationale - other destructive operations, e.g. reset emulator, clear volume, have No as a default - meaning that accidentally pressing Enter does not perform an operation that cannot be undone. I've made snapshot remove consistent with the rest here - @anisaoshafi would love to hear your opinion since you worked on snapshots recently IIRC.

tiurin · 2026-08-18T14:02:37Z

+	vertical bool
 }

+func (e UserInputRequestEvent) Prompt() string { return e.prompt }


Adding accessors for fields that are package-private now - they need to be read by rendering code in other packages, e.g. in app.go.

Co-Authored-By: Claude <noreply@anthropic.com>

gtsiolis

Clean refactor moving UserInputRequestEvent construction behind three intent constructors (Confirm/ActionChoice/Acknowledge) with private fields, migrating every call site and its tests, and centralizing shortcut derivation in OptionLabel.

thought(non-blocking): on internal/snapshot/remove.go — this quietly changes user-facing behavior: the old delete prompt used labels {Y, n}, so ENTER confirmed the delete, whereas Confirm(DefaultNo) makes ENTER cancel it. That's strictly safer for an irreversible op and is covered by the new [y/N] assertion, but a behavior change riding inside a "refactor" PR is easy to miss — worth a line in the description so reviewers know it's intentional. (Same applies to reset/volume clear, though those already defaulted to No.)
praise: the coverage migration is careful — the app-level tests that could only be built from hand-rolled option shapes are removed, and their rules (explicit-enter priority over an uppercase default, non-letter labels, any-key priority) are already exercised directly against resolveOption in TestResolveOption, so nothing is actually lost.

Automated review on behalf of @gtsiolis.

Generated by Claude Code

tiurin · 2026-08-18T18:08:01Z

thought(non-blocking): on internal/snapshot/remove.go — this quietly changes user-facing behavior: the old delete prompt used labels {Y, n}, so ENTER confirmed the delete, whereas Confirm(DefaultNo) makes ENTER cancel it. That's strictly safer for an irreversible op and is covered by the new [y/N] assertion, but a behavior change riding inside a "refactor" PR is easy to miss — worth a line in the description so reviewers know it's intentional. (Same applies to reset/volume clear, though those already defaulted to No.)

👍 This change was already mentioned in the self-review: #459 (comment). But I agree it is worth highlighting in the PR description. Added.

tiurin added semver: patch docs: needed Pull request requires documentation updates labels Aug 13, 2026

tiurin changed the title ~~Build prompts from intent constructors instead of a layout flag~~ refactor: Build prompts from intent constructors instead of a layout flag Aug 13, 2026

tiurin mentioned this pull request Aug 13, 2026

Improve slow-start prompt behavior #457

Merged

tiurin added docs: skip Pull request does not require documentation changes and removed docs: needed Pull request requires documentation updates labels Aug 13, 2026

tiurin force-pushed the prompt-intent-constructors branch 2 times, most recently from 8ea1c73 to d063210 Compare August 17, 2026 13:57

tiurin commented Aug 18, 2026

View reviewed changes

tiurin and others added 7 commits August 18, 2026 16:07

Build prompts from intent constructors instead of a layout flag

cb66286

Co-Authored-By: Claude <noreply@anthropic.com>

Seal prompt construction with unexported fields instead of a guard test

8beda7e

Co-Authored-By: Claude <noreply@anthropic.com>

Pin the snapshot remove confirmation's no default in an integration test

595df1d

Co-Authored-By: Claude <noreply@anthropic.com>

Simplify comments

312958d

Simplify comments

b0c1ee6

Clarify new point in review-pr skill

734c5f7

Make new claude instructions less verbose

49745bc

tiurin force-pushed the prompt-intent-constructors branch from f07e12d to 49745bc Compare August 18, 2026 14:07

tiurin marked this pull request as ready for review August 18, 2026 14:11

tiurin requested review from a team and peter-smith-phd as code owners August 18, 2026 14:11

tiurin requested a review from gtsiolis August 18, 2026 14:12

tiurin changed the title ~~refactor: Build prompts from intent constructors instead of a layout flag~~ refactor: Build user input prompts from intent constructors Aug 18, 2026

tiurin changed the title ~~refactor: Build user input prompts from intent constructors~~ refactor: Build user input prompts with intent constructors Aug 18, 2026

gtsiolis approved these changes Aug 18, 2026

View reviewed changes

Navigation Menu

Uh oh!

refactor: Build user input prompts with intent constructors - #459

refactor: Build user input prompts with intent constructors#459
tiurin wants to merge 7 commits into
mainfrom
prompt-intent-constructors

tiurin commented Aug 13, 2026 •

edited

Loading

Uh oh!

tiurin left a comment •

edited

Loading

Uh oh!

tiurin Aug 17, 2026 •

edited

Loading

Uh oh!

tiurin Aug 17, 2026

Uh oh!

tiurin Aug 17, 2026

Uh oh!

tiurin Aug 18, 2026

Uh oh!

tiurin Aug 18, 2026

Uh oh!

tiurin Aug 18, 2026

Uh oh!

tiurin Aug 18, 2026

Uh oh!

gtsiolis left a comment

Uh oh!

tiurin commented Aug 18, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

tiurin commented Aug 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Motivation

Solution

Behavior changes

Review

Validation

Uh oh!

tiurin left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tiurin Aug 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tiurin Aug 17, 2026

Choose a reason for hiding this comment

Uh oh!

tiurin Aug 17, 2026

Choose a reason for hiding this comment

Uh oh!

tiurin Aug 18, 2026

Choose a reason for hiding this comment

Uh oh!

tiurin Aug 18, 2026

Choose a reason for hiding this comment

Uh oh!

tiurin Aug 18, 2026

Choose a reason for hiding this comment

Uh oh!

tiurin Aug 18, 2026

Choose a reason for hiding this comment

Uh oh!

gtsiolis left a comment

Choose a reason for hiding this comment

Uh oh!

tiurin commented Aug 18, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

tiurin commented Aug 13, 2026 •

edited

Loading

tiurin left a comment •

edited

Loading

tiurin Aug 17, 2026 •

edited

Loading